This invention relates to electronic programmable controllers for operating industrial equipment, and more particularly, to a programming language used to develop control programs performed by industrial controllers to control industrial equipment.
Programmable controllers are well-known systems for operating industrial equipment, such as assembly lines and machine tools, in accordance with a stored program. In these controllers, a stored program is executed to examine the condition of specific sensing devices on the controlled equipment, and to energize or de-energize selected operating devices on that equipment contingent upon the status of one or more of the examined sensing devices. The program not only manipulates single-bit input and output data representing the state of the sensing and operating devices, but also performs arithmetic operations, timing and counting functions, and more complex processing operations.
One industry which extensively uses programmable controllers is the automotive industry. In the automotive industry, various automotive parts are conveyed along machine lines consisting of many consecutive workstations. Most workstations include at least one tool which performs some function to alter the characteristics of workpieces as they are delivered to the station, For example, an unfinished cast engine block that requires a plurality of holes, bores, and threads, as well as other metal-removing procedures, may be provided at the beginning of a machine line that produces finished engine blocks. The machine line may consist of any number of different stations, each station performing a different procedure on the unfinished block. An indexer in the form of a transfer bar can be arranged to move each block from one station to the next following a completed process. Typically, at each station the block would be clamped prior to any metal-removing operation.
In this type of system, a programmable controller would receive inputs from all of the various tools at all of the workstations and would provide activating output signals to synchronize machine operation. During metal-removing periods with the transfer bar out of the way, all of the tools would perform their functions. In between metal-removing periods during transfer periods, the tools would be parked, the clamps unclamped, and the transfer bar would advance workpieces from one station to the next.
Industrial controllers are frequently programmed in "relay ladder" language (RLL) where instructions are represented graphically by "contacts" and "coils" of virtual relays connected and arranged in ladder-like rungs across power rails. RLL, with its input contacts and output coils, reflects the emphasis in industrial control on the processing of large amounts of input and output data.
RLL also reflects the fact that most industrial control is "real time"; that is, an ideal industrial controller behaves as if it were actually composed of multiple relays connected in parallel rungs to provide outputs in essentially instantaneous response to changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay-like structures, but instead simulate the parallel operation of the relays by means of a conventional Von Neumann-type computer processor which executes instructions one at a time, sequentially. The practical appearance of parallel operation is obtained by employing extremely fast processors in the execution of the sequential control program.
As each rung is executed, inputs represented by the contacts are read from memory (as obtained from inputs from the controlled process or the previous evaluation of coils of other rungs). These inputs are evaluated according to the logic reflected in the connection of the contacts into one or more branches within the rungs. Contacts in series across a rung represent boolean AND logic whereas contacts in different branches and thus in parallel across the rung represent boolean OR logic.
Typically a single output coil at the end of each rung is set or reset and, based on the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a bit (which ultimately becomes an output to the industrial process or to another RLL rung).
Once a given rung is evaluated, the next rung is evaluated and so forth. In the simplest form of RLL programming, there are no jumps, i.e. all rungs are evaluated in a cycle or "scan" through the rungs. This is in contrast to conventional computer programming, where branch and jump instructions cause later instructions or groups of instructions to be skipped, depending on the outcome of a test associated with those branch or jump instructions.
While RLL is well-suited for controlling industrial processes like those in the automotive industry, RLL programming is not an intuitive process and, therefore, requires highly-skilled programmers. Where hundreds of machine tool movements must be precisely synchronized to provide a machining process, programming in RLL is extremely time-consuming. The time and relative skill associated with RLL programming together account for an appreciable percentage of overall costs associated with a control system. In addition, the final step in RLL programming is typically a lengthy debugging and reworking step which further adds to overall system costs.
One way to streamline any type of programming is to provide predefined language modules, expressed in a language such as RLL, which can be used repetitively each time a specific function is required. Because of the similar types of tools and movements associated with different machine-line stations, industrial control would appear to be an ideal industry for such language modules.
The predefined logic module approach works quite well for certain applications, like small parts-material handling or simple machining. The reason for this is that the RLL logic required for these applications tends to be very simple. In small parts material handling applications the I/O count is low and the interfaces between modules are minimal. In fact, the mechanisms are often independent units, decoupled from neighboring mechanisms by part buffers such that no signals are required to be exchanged between modules. These "loosely coupled" systems lend themselves to "cut and paste" programming solutions.
But the predefined, fixed logic module approach does not work well for other applications, for example metal-removing applications. There are two main reasons for this. First, there can be considerable variation in how components, such as sensors and actuators, combine to produce even simple mechanisms. Second, processes like metal removing normally require tightly controlled interaction between many individual mechanisms. The interaction is controlled by exchanging signals, called interlocks, between the control logic modules of the individual mechanisms. The application of specific interlocks depends on knowledge of the process and the overall control strategy, information not generally needed, or knowable, when the control logic for each mechanism is defined.
For example, a drill is a typical metal-removing tool used in the automotive industry. In this example an ideal drill is mounted on a carriage that rides along a rail between two separate limiting positions on a linear axis, an advanced position and a returned position. Two limit switches, referred to herein as returned and advanced LSs, are positioned below the carriage and, when tripped, signal that the drill is in the returned and advanced positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the advanced and returned positions are reached, respectively. In the ideal case, both LSs may be assumed to be wired in the same "normally opened" manner, so that electrically speaking they are open when released and closed when triggered. In this ideal case, where the physical characteristics of the switches are limited, a single RLL logic rung can determine when the drill is in the returned position and another rung can determine when the drill is in the advanced position.
Unfortunately, in reality, there are electrically two types of LSs, one LS type being wired normally opened and the other type wired normally closed. Furthermore, any LS can be mechanically installed in a tripped when activated configuration, or a released-when-activated configuration. All combinations of these types are used for various types of applications. Thus, application requirements may demand control logic capable of handling any configuration of LS types.
Simple mathematics demonstrates that with two different electrical types of LSs and two mechanical configurations, there are sixteen possible configurations of a two-position linear slide. Consider the language modules required to implement position logic for all these configurations. To accommodate all sixteen switch configurations, there could be sixteen different language modules, each containing fixed RLL logic, and each named for the case it could handle. In this case, there would be duplicate logic under different names. Alternatively, four unique language modules could be provided, but then the user would have difficulty identifying which of the sixteen physical configurations could be handled by which of the four modules.
Clearly, even for a simple drill mounted on a two position linear slide, application variables make it difficult to provide a workable library of fixed language modules. Adding more switches to the linear slide only increases, to an unmanageable level, the number of language modules required in the library.
Moreover, the contents of a complete language module for a drill must also consider other variables: including the number and type of actuators required; the type of spindle, if any; whether or not a bushing plate is required; what type of conveyor is used; whether or not the drill will include an operator panel to enable local control; and, if an operator panel is included, what type of controls (i.e. buttons, switches and indicator lights) are required; just to name a few. Each tool variable increases the required number of unique RLL modules by more than a factor of two, which makes it difficult at best to provide an RLL library module for each possible drill configuration.
Taking into account the large number of different possible machine-line tools, each tool having its own set of variables, the task of providing an all-encompassing library of fixed language modules becomes impractical. Even if such a library could be fashioned, the task of choosing the correct module to control a given tool would probably be more difficult than programming the required RLL logic from scratch.
For these reasons, although attempts have been made at providing comprehensive libraries of fixed language modules, none has proven particularly successful and much RLL programming is done from scratch.
Therefore, in order to reduce programming time and associated costs, it would be advantageous to have a more flexible means of specifying control logic that provides for the specification of truly reusable sections of RLL or other control logic. Furthermore, it would be advantageous if a library of reusable modules enabled industrial engineers less-skilled in programming to provide complete control logic programs and to reduce required debugging time. Finally, it would be advantageous if such a library of reusable modules could be accessed using a programming apparatus such as a personal computer, or the like, to further minimize programming time and cost.